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SECTION 1 
SUMMARY 

This document It Task Report 3, TR-3. of the Simulation Verification 
Techniques Study, Contract NAS 9-13657. Specifically, this report presents 
system level self test concepts and requirements for simulator Self Test. 

Testing techniques for training simulators are discussed In Section 3. 

Three categories of testing are covered: Readiness Tests, Fault Isolation 
Tests, and Incipient Fault Detection Testing. Readiness Tests are generally 
end to end functional tests. Fault Isolation Tests are performed at a lower 
level of hardware detail and therefore point out the faulty LRU when a failure 
occurs. Various techniques for Incipient Fault Detection are discussed in 
light of their applicability to various simulator subsystems. Incipient Fault 
Detection Testing was found to be most useful In decreasing unscheduled maintenance 
of the Motion Base System, Visual Simulation, both video and model components, . 
and servo driven Instruments. Readiness Tests are Intended to be performed 
on a dally basis. 

Self Test software requirements are discussed In Section 4. The proposed 
software structure Is based on an executive that controls test operations. Includ- 
ing test software loads for various subsystem tests, checks test results to 
determine the next test step, and assembles test results for output to the 
operator, to hardcopy devices for permanent records or to mass storage files 
for updating of the Incipient fault detection data base. The executive Is a 
batch program that allows the subsystems test software to establish dat* rates 
and sampling rates. Accurate timing data Is obtained by time tagging data 
words at the time they are sampled. 

The total hardware requirements for Implementation of the Self Test System 
are listed In Section 5. Largest test hardware requirements In terms of cost 
Is In the Visual Simulation CCTV subsystem. In terms of numbers, the Instru- 
mentation for the various controls and displays on the Crew Station and I0S 
are most demanding. 
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Section 6 discusses changes end modifications, primarily In the vehicle and 
payload complement, and the Impact that these changes will have on Simulator 
Configuration, Self Test System, and Data Base make up. Changes discussed here 
are only those that would take place after Installation-end acceptance of the 
simulator. 

• • 

Relative cost data of the Self Test components to the basic simulator 
subsystems and to each other are presented In Section 7. Self Test of Visual 
Simulation CCTV subsystem and the Crew Station and IOS were found to represent 
the most significant portions of the total Self Test System cost. Conclusions 
and recommendations, as they pertain to the overall Self Test System Requirements 
and Implementation are documented In Section 8. 
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SECTION 2 
INTRODUCTION . 

This report presents software end hardware requirements for Implementing 
hardware self test as defined during the Simulation Verification Techniques 
Study being conducted for NASA's Johnson Space Ceriter under Contract NAS9-13657. 

This study Is being performed by McDonnell Douglas Astronautics Company - East 
at Its Houston Operations facility. Keith L. Jordan, Simulation Development 
Branch, FSO, Is Technical Monitor of the contract for the NASA. 

The Simulation Verification Techniques Study Is one of a number of studies 
being conducted by NA$A-JSC In support of the development of training and pro- 
cedures -development simulators for the Space Shuttle Program. The other studies * 
consist of the following: Shuttle Vehicle Simulation Requirements, NAS9-12836; 

Space Shuttle Visual Simulation System Design Study, NAS9-12651, performed by 
McDonnell Douglas Electronics Company; Development of Simulation Computer 
Complex, NAS9-12882; and Crew Procedures Development Techniques, NAS9-1 3660; 
both of the latter were performed by McDonrell Douglas Astronautics Company - 
East at Its Houston Operations facility. 

The present study Is concerned with the development of self test techniques 
for simulation hardware and the validation of simulation performance. A pre- 
liminary report for the Hardware Verification Task has already been published. 

The present report presents the results of an analysis of the requirements of 
an Integrated simulator self test system. This system consists of the additional 
hardware and software required for a training' simulator In order to provide 
maximum reasonable self test capability. The results In this report will be 
Incorporated In the final version of the "Simulation Self Test-Hardware Design 
and Techniques Report" to be published shortly. 
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SECTION 3 

INTEGRATED SYSTEM TEST DESCRIPTION 

Tilting of tht simulator as an Intigratid system Involves the sequential, 
and sometimes concurrent verification of simulator subsystems and functions. 

Then an three hierarchical classifications of tests determined by the level 
of detail to which the test Is performed and the level of confidence obtained 

after successful completion of the test. These classifications an Readiness 

• • 

Tests. Fault Isolation Tests, •;«. Incipient Fault Detection Tests. 

3.1 READINESS TESTS 

Readiness Tests an used to verify the nadlness of simulator subsystems 
to perform according to design and operational nqul rements. Generally these 
tests check each of the simulator subsystems and, whenever possible, use 
alnady verified subsystems to check other subsystems. of the simulator. Ideally 
nadlness tests an end to end tests. They an primarily concerned with test- 
ing • complete string of hardwan. 

The sequence of subsystem testing developed In the course of this study 
Is based on the "building block" appnach of establishing the operational 
nadlness of a system element before that element can be used to test other 
portions of the system under test, In this case the simulator. Flgun 3.1-1 
shows the sequential and parallel arrangement for test execution during the 
Readiness Test. Individual tests shown at the same horizontal level can be 
. executed simultaneously by the various relatively Independent processors In 
the simulator. Checkout of the HOST computer Is nqulred prior to commencing 
with simulator checkout. 

Each of the vertical strings indicate dependence of tests, lower on the 
chart, on successful completion of previous tests. For example, the simulator 
Interface minicomputer must pass successfully Its readiness self test prior to 
executing the routines for DCE self test. Failure of the minicomputer to pass 
this test would return Information to the HOST regarding the point or function 
at which the test failed. On the other hand, a failure In the DCE would prevent 
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Crew Station or Visual Simulation system checkout; and It would bo up to HOST 
computer scftwaro to determine what automatic fault Isolation tosts should 
bn run on tho OCE. 

Thn stlf tnst softwam Is. Initially In massstorage elements of tha HOST 
computer complex, and Is loadad Into tha system undar control of and 
through tha Intarfaca facllltlas of tha HOiT computer. At tha conclusion of 
tha load, aach procassor returns to tha HOST a message Indicating that tha 
load has bean completed, and soma other Information such as a checksum which tha 
HOST can than use to verify that a successful, accurate load has bean accomplished. 

After the loading process Is completed, and the HOST has verified that all 
want well, each processor Is comnanded by the HOST to execute tha subsystem 
Saif Test programs. 

, a * 

The simulator processing elements that receive this self test software 
load are the Flight Equipment Intarfaca Oevlce processors; tha simulator Inter- 
face for tha DCE, crew station, visuals, and motion base; and the IOS Graphics 
minicomputer. Tasting of tha Flight Computers Is not performed until after 
tha FEID Is thoroughly checked out; therefore, loading of tha Flight Computer 
self test software does not taka place until after completion of FEIO Self Test. 
This particular sequence Is necessary because FC Self Test requires correct 
performance of FEIO hardware not only during the load, but also In checking 
FC capability to communicate with avionic components external to the FC and 
simulated by tha FEIO. 

Completion of aach level of Readiness Tests results In control being returned 
to the HOST, which then logs any subsystem operational data gathered during the 
test, Issues appropriate messages to the Test Operator, and determines the next 
logical step In the test sequence. 

The following sections discuss briefly the nature and extent of the 
Readiness test for each of the major simulator subsystems. 
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3.1.1 FEIO Readiness Tests 

The major elements of tho FEIO tested during tho Readiness Tost art tho 
processors end-the various Intarfacot. Tho typo* of Usts performed on thota 
alamonts. at wall at tho Cantral Buffer Storaga, art such that thorough and 
progrtttlvt chock* art made on tach portion of tho FEIO. Fallurt to pat* ont 
of tho*# ta«ti immediately points to a fault In tho LRU btlng tostod. and 
thtrtfort that* tasts. by thalr thoroughntss and Itvtl of datall. obvlata tha 
naad for fault Isolation tasts. 

• a 

At tha completion of FEIO Raadlnass Tost, tha HOST Is Infonntd of which 
LRU's. If any, havt failed and rtqulrt repair or replacement action. Tha HOST 
can than report this Information to the tost operator, together with possible 
diagnostic Information that would aid the maintenance personnel In repairing 
faults detected. 

3.1.2 FC Readiness Tests 

The Flight Computer elements, as is the case with the FEIO, will be 
thoroughly checked during the Readiness Tests. The subsystem level self test 
analysis Indicated that automatic testing of the FC's should rely on using 
vendor supplied diagnostic software. This software will be available, and 
will yield a higher level of confidence on readiness of the flight hardware 
than would be likely to be achieved by software developed especially for 
simulator application. 

Use of test software supplied by the FC manufacturer will provide an adequate 
level of fault Isolation. For the FC's, therefore, no additional fault Isola- 
tion tests are recommended. 

3.1.3 Simulator Interface Computer and IQS -Graphic. Kiplcomput.r R.»d1n. M T«»t» 

The simulator Interface computer and the graphics computar are commercially 

available computer systems. These computers will be ly procured for the 
specific simulator applications. As part of that procurement. It will be necessary 
to assure that these computers have available adequate software for accomplishing - 
functional checks of the basic computer elements. In implementing these functional 
tests, the faults which may be detected are Imnedlately related to the LRU level. 
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Consequently no special fault Isolatldn tests art required for these computers. 

The test capabilities required for the functional test software are discussed 
.as part of the analyses of the ancillary computers for the simulator configurations 
considered for this study. 

3.1.4 DCS Readiness Test 

The DCE Readiness Test, as developed during the subsystem analysis portion 
of the study, consists primarily of switching output bilevel and analog channels 
on to Input channels. Generation of predetermined outputs Is followed by 
measuring corresponding Inputs and then determining that Input patterns, for 
bilevel DCE» or values, for analog DCE, agree with the outputs. This type of 
test adequately verifies the health status of each Individual channel, and If 
a failure occurs, can point to or Isolate the pair of channels. Input and output, 
where a fault might exist. 

3.1.5 Crew Station/ IQS Readiness 

The crew station contains a variety of display, control, and Instrumentation 
components. These are both digital and analog devices, and within these cate- 
gories there are significant differences In the physical, electrical and 
performance characteristics of the many components used. This variety prevents 
{he use of functional performance testing of groups of components and requires 
that each Individual meter or switch be tested Individually to ascertain 
Readiness. This component by component test approach during the Readiness 
Test leads directly to fault Isolation and Identification of the faulty components 
without any additional Crew Station Fault Isolation Test. 

3.1.6 Motion Base Readiness Tests 

The motion base readiness testing consists of two basic elements. The first 
of these Is the monitoring of sensor levels during power on and power off static 

checks. The second element Is the analysis of dynamic test data to assess motion 

• ' 

base dynamic performance adequacy. The dynamic test data may be obtained either 
from specially executed motions as part of the readiness test or It may be 
data accomulated on-line during the previous operational period. 

The sensor data directly Identifies faults In the systems since It monitors 
specific parameters such as hydraulic fluid level or pressure drop across a filter. 

There Is no additional requirement for fault Isolation with respect to these parameters. 
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However. the dynamic data obtained for a synergistic motion bate can ba 
chocked for proper performance without any Insight being obtained Into the likely 
source*, of out of specification performance for the actuator servo systems. Fault 
Isolation analyses may be applied to obtain the desired Insight. 

• • 

3.1.7 Visual Simulation Readiness 

End to end testing can be used successfully In establishing operational 
readiness of the Visual Simulation System. Enough Information can be gathered 
by Inserting a test signal at the CCTV camera and taking measurements at CRT grids 
to determine whether performance of the video equipment Is acceptable to 
proceed with normal simulator operations. The servo systems that control probe, 
camera, and model motion can also be checked using functional end to end 
testing. As In the other subsystems, fault Isolation testing Is only Initiated 
when a fault Is detected during the Readiness Test. Failure data Is furnished 
to the ffcult Isolation software to determine which tests to run, and which strings 
of hardware to test during the fault Isolation process. 
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3.2 FAULT ISOLATION TESTS 

Fault Isolation Lasts are performed following a failure during normal 
operation or after detecting a fault during the Readiness Tests* In order to 
localise the fault or source of failure to a line replaceable unit (LRU). 

This localisation Is required to permit prompt repair by replacing the failed 
LRU. Whereas Readiness Tests can be performed at the functional level (the 
ability to generate an audio tone with the Aural Cues System)* ‘he Fault 
Isolation Tests are performed at the hardware LRU level (verifying that the 
analog signal output from a OAC corresponds to the digital pattern Input to 
It). Fault Isolation Tests* because they go to a lower level of hardware 
detail* are more exhaustive* take more time to run on any particular subsystem* 
and achieve a higher level of confidence on the health of the hardware than 
achieved by Readiness Tests. 

There are subsystems that because of their characteristics* must be tested 
In detail In order to ascertain an acceptable level of readiness. These subsystems 
are not addressable by higher level* functional testing as part of the dally 
Readiness Test. These subsystems Intrude the Flight Equipment Interface Oevlce* 
FEID* the Flight Computers* the computers for the Simulator and graphics Inter- 
faces* and the Craw Station and IOS Instrumentation, displays and controls. 

The readiness tests for these subsystems, as discussed In the previous section* 
effectively Isolate faults to the LRU level required. 

There are, however* several subsystems that are suitable for extended 
testing for fault Isolation or In fact, require quite extensive additional 
testing In order to achieve Identlfacatlon of defective LRU's. These consist"*' 
of the Data Conversion Equipment, the Notion Base* the Visual Simulation 
Subsystems, and the Aural Simulation subsystem. The Fault Isolation Test 
requirements for these subsystems are discussed 1r. the fbl lowing paragraphs. 

3.2.1 DCE Fault Isolation Tests 

At the end of the Readiness Test, the HOST Is Informed of the pairs of 
channels* If any, where faults were detected. The Test Operator Is given this 
Information and the option to terminate OCE testing or to command the HOST 
to Initiate the DCE Fault Isolation Test. It Is possible that the channels 
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that failed readiness tasting art spare channels, not In use, and therefore 
no further fault Isolation Is required. On the other hand. If the channel Is 
In use, the operator may patch around the faulty channel by making the necessary 
hardware and software data bate changes to permit the use of alternate channels. 
This course of action may expedite activation of the simulator and obviate the 
need for fault Isolation and maintenance operations, which would then be deferred 
to a more convenient, lower Interference time. 

a • 

If the Test Operator chooses to perform automatic fault Isolation, he 
notifies the HOST and Initiates loadlnq and execution of the DCE Fault Isolation 
Tests. The objective of these tests is to determine which LRU In the DCE Is 
faulty and therefore should be replaced or repaired. 

The first step In the DCE fault Isolation process Is to determine whether 
the faulty channel In the suspected pair Is the output or the Input. This 
can be accomplished, as discussed In previously documented DCE Self Test 
analysis. If the fault Is determined to be In ah output bilevel channel, the 
fault Isolation process continues to determine whether the faulty LRU Is the 
digital output routing and address decoding logic, or the memory and drive 
circuitry. If the fault Is In the bilevel Input channel, then the Isolation 
process will localize the fault In the Input multiplexer and address decoder 
logic, or the bilevel signal receiver circuit. Problems In a pair of analog 
channels will cause the fault Isolation testing procedure to determine whether 
the faulty LRU Is the DAC or analog driver In the output, or the Buffer Amplifier 

or ADC In the Input. The fault Isolation process for both bilevel and analog^ 

# * 

channel LRU's has already been documented In the Self Test Design and Techniques 
analysis portion of the study. 

3.2.2 Motion Base Fault Isolation 

Although many of the components that may require periodic servicing can 
be measured by direct sensing, the Isolation of faults based on degradation of 
hydraulic actuator system performance Is a factor that may be amenable to 
analysis. Fault Isolation Tests for the motion base require consideration 
of the frequency response of the servo systems or servo loops of which the 
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hydraulic actuators art tha major components. Doflnltlon of tho frequency 
response enables comparison of breakpoint data with fault dictionary Information 
which Is established by simulation of the motion base actuator servo systems. 
Analysis of this data then permits Identification of the particular components 
or likely components which are causing the degraded performance. 

3.2.3 Visual Simulation Fault Isolation 

In the Visual Simulation System there are two major type! of hardware: 
one Is the primarily electronic elements which make up the Closed Circuit 
Television system and Include camera, camera control, video processing, display 
switching and the displays themselves. The other type Is the electromechanical, 
servo controlled elements used to move and position the various components of 
the camera/model based simulation. This type Includes the spherical earth 
models, the camera gantry and Its driving system, and the probe pointing 
attitude control servo systems. The fault Isolation approach for the CCTV 
components Is based on a progressive test of succeeding LRU's In the video 
string until the failed LRU Is switched In and unusual performance degradation 
Is detected. On the other hand, fault Isolation for the model drive components 
concentrates on analyzing that control string which exhibited unacceptable 
performance during the Readiness Test. Characteristic parameters of each 
LRU In that string are measured In order to ascertain operational status of 
each LRU and determine which Is the one that has failed. The actual sequence 
of fault Isolation tests for each string of hardware has alrt'.dy been documented 
In the Visual Simulation System Self Test Analysis part of the study. 
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3.3 INCIPIENT FAULT DETECTION 

• • 

This section covers Incipient fault detection testing techniques and their 
applicability to simulator hardware. First of all, a set of criteria to determine 
which components can profit from this third class of testing Is discussed. 

Then various methods to perform Incipient fault detection are presented with 
emphasis on the one selected, that of gathering historical operational data 
and looking for trends that point to eventual failure of a component. The 
applicability criteria were applied to all the simulator subsystems, and a 
set of relevant parameters, along with processing techniques were defined for 
each of the subsystems that could benefit from Incipient fault detection. 

These parameters and techniques are documented for each subsystem at the end 
of this section. 

3.3.1 Incipient Fault Detection Criteria 

The primary objective of Incipient fault detection testing Is to Identify 
potential failures before they occur. This objective becomes quite Important 
In components that require extensive simulator downtime to repair or replace. 

For example, an electronic module can be replaced In seconds, and If It falls 
during simulator operation, only a few minutes would be lost from the training 

schedule. On the other hand, If a hydraulic fluid accumulator ruptures. It 

• * • 

would take hours to replace, If a spare were available, and even longer to 
repair, reassemble the plumbing, and recharge the hydraulic system to replace 
the lost fluid. In the first case, the payoff from Incipient fault detection 
Implementation Is measured In minutes saved when the weakening module Is 
replaced during non operational time. In the latter case, Incipient fault 
detection analysis can point to the sticky, valve, the surging pump, or the 
clogged filter that could eventually result In rupture of the accumulator. 

This Information could be used to replace or repair the faulty component during 
a more convenient maintenance shift, Instead of having to face the situation 
described above that would cause the loss of one or several training shifts, 
following rupture of the accumulator. 

This example Illustrates the primary criterion used In determining which 
subsystems should be analyzed for possible application of Incipient fault 
detection techniques: If an LRU In a system requires more than one hour for 
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replacement or repair, th« operational effectiveness of the system can be 
Increased by the use of techniques that will Identify a potential failure 
of that LRU, so that replacement or refurbishment can be effected during 
scheduled maintenance time. This criterion would apply to devices that, 
although easily replaced, a spare unit Is not normally kept on hand because 
of Its high cost coupled with high reliability of the device. 

The second criterion In determining applicability of Incipient fault 
detection Is the physical and functional nature of the LRU Involved. Some 

components, notably solid state electronic circuit elements, do not exhibit 

• , 

degradation characteristics that can point to eventual failure. These devices 
usually fall as a result of a single overstress condition that causes fusion 
or breakage of the delicate semiconductor material, thereby changing the 
electronic characteristics of the unit. It Is not possible to predict a 
failure In this type of circuitry, and even though It may be desirable to do 
so because of maintainability considerations, no known Incipient fault detection 
technique can be effectively applied here. 

On the other hand, there are LRU's, notably electromechanical devices, 
that do age and wear out either because of nechanlcal function or by chamlcal 
changes within the device. For example, an electrical motor may exhibit 
erratic starting characteristics. This condition may be an Indication that 
the bearings or seals have worn down, or that capacitors In the starting 
circuitry have aged to the point that eventually a failure might occur that 
could require extensive overhaul of the motor. Early detection of the Incipient 
fault permits scheduling of overhaul as part of normal maintenance operations. 
However, this early detection can only be effected on components that degrade 
or age to the point that may eventually result In a failure. 

To suimarlze then, the two basic criteria for determining applicability 
of Incipient fault detection techniques to a particular subsystem are: 

1. Maintainability characteristics of the LRU must be such that repair 
or replacement time would exceed one hour. 
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2. Physical, functional and aging characteristics of the LRU art such 
that unit Integrity degrades with tine to an unacceptable or failure 
level* rather than falling catastrophlcelly and unpredlctably. 

3.3.2 Indolent Fault Detection Technique 

Various techniques for performing Incipient fault detection were analyzed 
during Subtask 1.2 of the study, and are documented In more detail In tee 
previously published Self Test Techniques Report. They are reviewed here for 

reference. The four techniques analyzed were: 

• ♦ 

1. Overstr*M Testing. The LRU Is operated at the high end or beyond 
the high stress limit of the operational band. This overstress 
operation should be within the safety margin normally encountered 
In hardware design. If operation Is faulty* It may be a symptom of 
possible future failure. Examples of this type of testing are fre- 

• 

quency response tests at higher frequencies than required In normal 
operation, or testing of electrical components at higher voltage than 
the maximum specified for normal performance. The greatest disadvantage 
to this technique Is that It may force a failure at a time when .main* 
tenance would Impact simulator operational schedule. If properly 
scheduled, however, this technique could be a useful tool to detect 
weaknesses In some simulator components. 

2. Marginal Testing. The LRU Is operated at tee low end or beyond the 
low stress limit of the operational band. This technique, like 
overstress testing can be used to detect degradations In components 
that may lead to a failure. Examples of marginal testing would be 
running the motion base with lower than normal hydraulic fluid system 
pressure, or slewing a camera gantry slowly enough to find sticky 
points along the range of travel that Ihdlcate a possible accumulation 
of dirt on the track, or flaws In the driving mechanism that can 

lead to a future failure. 
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3. Grey Art* Ptrformtnct Otttctlon. Tht LRU It tested within Its normal 
band of opt rati on, but a warning It Ittutd whtn ptrfonaanct drops 
btlow a prtdtflntd Itvtl. This ttchnlqut assumts progrttslvt ptr- 
formanct dtgradatlon which becomes a fallurt btlow a prtdtflntd Itvtl. 
If a hlghtr Itvtl It dtflntd to ertatt a warning or N grty N arta, then 

• i . 

performance within this arta, although acceptable, It an Indication 
that the unit hat degraded to such a point that a failure will soon 
occur. Simulator operations personnel should then schedule maintenance 
of the LRU In order to preempt the actual occurence of the failure. 

4. Rate of Degradation. Measure and record historical data on a parameter 
that Indicates degradation of performance In a particular LRU, and 

use this data to compute rate of degradation. If this rate Increases 
or changes markedly, It may point to an Imnlnent failure of the unit. 
The amount of time during which historical data Is recorded depends 
on the nature of the component and the slope of the normal or average 
degradation function for that type of component. 

If degradation .takes place very fast, as In the case of a slightly 
ruptured hydraulic filter that through usage might enlarge the rupture 
and eventually break down, then there Is no need to store data for 
months. Information gathered for the last five days may be enough to 
Indicate that something has happened to the device, and that Its 
performance Is fast degrading and that soon a failure will occur. On 
the other hand, a slowly degrading component such as an electrolytic 
capacitor may require processing of data acquired for a period of 
weeks to Indicate that the component has reached Its "last leg" In 
the degradation function, and that soon It will fall totally. 

Techniques number 3 and number 4 are the ones that offer the greatest value 
for simulator Incipient fault detection testing. Their advantages lie In that 
no unusual operational conditions have to be created, and therefore, normal 
operation or readiness testing exercises can be used to gather the necessary 
data to detect incipient faults. Therefore, these techniques do not need 
additional test hardware or control software beyond that which Is required to 
perform the Readiness Tests or Fault Isolation Tests. 
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3.3.3 Incipient fault Oetectlon Implementation •. n 

Using the Incipient Fault Oetectlon Applicability Criteria In analyzing 
simulator subsystems* It was determined that Incipient fault detection tech- 
niques would benefit the operational utility of the following subsystems: 

- Hydraulic Motion Base System 

- Visual Simulation Video Components 

• Visual Simulation Model Drives and Controls* 

- Servo Driven Instrumentation 

These are the system elements that exhibit progressive degradation character- 

• • 

Istlcs and would require the simulator to be out of service a substantial period 
while maintenance takes place. Table 3.3-1 summarizes the use of Incipient 
fault detection techniques on each subsystem. Integration of these techniques 
Is a part of recommended self test procedures. 


TABLE 3.3-1 INCIPIENT FAULT DETECTION TECHNIQUES APPLICABILITY 


SYSTEM ELEMENT 

INCIPIENT’ FAULT DETECTION TECHNIQUES 

Overstress Marginal Gray Area Rate of 

Testing Performance Degradation 

Hyoraullc Motion Base System 

Visual Simulation Video 
Components 

Visual Simulation Model 
Drives And Controls 

Servo Driven Instrumentation 

XXX X 

X X x 

X XX 

• 

x X X 
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3.4 TEST SEQUENCING 

The thrM types of testing discussed above have been Integrated Into a 
recommended simulator self test concept. This self test approach It based 
on several assumptions and on the above description of* the basic nature of 

these tests when applied to specific simulator subsystems. The general test 

• • 

approach and test sequencing are most evident In the discussion of the Simulator 
Self Test Software Description presented In Section 4. In this section, we will 
review the rationale for test sequencing and distribution of test operations as 
It relates to the three types of testing Involved. 

The readiness tests are Intended to be overall functional tests for the 
various simulator subsystems and as such should require only a limited amount 
of time to execute. It Is assumed that the readiness tests would nominally be 
executed every day or at the beginning of each training shift. In the event 
that a failure or fault Is detected by the Readiness Test, It may be necessary 
to execute a Fault Isolation Test In order to Identify more precisely the LRU 
which Is the source of the problem. As previously discussed, this is only 
necessary In the case of the DCE, the motion base, the visual system and the 
aural simulations. 

If the fault Isolation test Is required, then a question arises as to 
whether It should be executed automatically or whether the operator should 
be required to Initiate the additional test by further positive action. In 
design of the test software, Section 4, automatic execution Is assumed since 
this establishes the necessary basic sequence elements. The Introduction of 
pauses or overriding Interrupt logic Is a relatively minor and optional problem 
when the software Is implemented. 

Figure 3.4-1 Illustrates the operational sequencing of Readiness, Fault 
Isolation, and Incipient Fault Detection Testing. The basic data for the 
Incipient Fault Detection Test can be obtained In most cases during the 
readiness test execution- as shown In this Figure. However, If a fault Is 
detected during the readiness test, then the data obtained should not be 
entered Into the Incipient Fault Detection data base. Tests for this contingency 
are shown In the software flows. 

• • 
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FIGURE 3.3-1 DAILY SELF TEST SEQUENCE 
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In summary, then, If the Fault Isolation Tests art Inltlatod automatically, 
tha opart tor will bo provided with an output which Idontlflot tho following: 
o Subtyatomi tat tad that havo succoiifully comp la tad tho roadlnttt chock 
o Sybsystems toitod that havo fallod tho roadlnosa. chock 
o Results of Fault Isolations Tests for faulty subsystems 
o Results of analyses of Incipient Fault Detection Test data. Including 
the following: 

o LRU's that have moved Into a gray area and are approaching 
an unsatisfactory level of performance — ~ 
o Projected failure dates/tlmes for near term critical LRU's 

The operator must then decide whether to constrain the type of activities 
allowed In simulator usage, or to Initiate maintenance or replacement of the 
components Identified as failed. The output from self tests then Is an Indi- 
cation of the readiness status of the system, Including Information helpful 
In trouble shooting or restoring any faulty functions or components of the 
Simulator. 



SECTION 4 

SIMULATOR SELF TEST SOFTWARE DESCRIPTION 
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The iliiulator >«1f test software hat batn designed and atructurad to at 
to Implement tha tatt sequences dltcuttad In Sactlon 3 with ratpact to both 
tha ordar of subsystem tatting and tha ordar In which tha various typat of 
tatti ara axacutad. Slnca tha simulators of Intaratt don't exltt currantly 
but ara axpactad to ba multi -computer systems with tatalllta procattort avallabla 
to handla Input/output procattlng, data reformatting. and othar nltcallanaoua 
oparatlont, It It Impottlbla to pradlct with much cartalnt y tha amount of 
computing powar avallabla In thata parlpharal procattort. Tharafora, It It 
alto Impottlbla to rationalize, at thlt point, tha dlttrlbutlon of talf tatt 
function! batwaan tha hoit computar and tha Intarfaca computers. At a result, 
tha approach taken In daslgnlng tha toftwara dafart that problam to a latar 
time and praianta tha toftwara ttructura to at to daflna hlararchlat of 
toftwara modulat. and tha nacattary sequencing of oparatlont and channalt of 
data communication. 

• 

A simulator talf tatt toftwara traa It shown In Flgura 4-1. Tha toftwara 
modulat ara Idantlflad by both an acronym, tultabla for programing uta. and 
a descriptive title. Tha modulat thown In thlt traa do not have tha ralatlonthlp 
utually Implied by a toftwara traa In tha tente that tha modulat at tha two 
lower levelt ara not tubprograms to tha modulat above them. Instead tha Impli- 
cation of tha structure of tha traa It that modulat at tha tame level may ba 
exerclted concurrently and Independently, retourcet permitting; all modulat 1n^ 
tha tame string but at a higher level must ba exercised successfully before 
that module may ba exercised; or. In othar words, tha modules In a string mutt 
ba exercised In a top down sequence. All of these modulat and programs will 
ba controlled In their execution by tha test executive and consequently In 
an ordinary tree would all ba shown directly connected to tha executive. Each 
of thata modulas It further described In detail In tha final report for tha 
hardware techniques task. In this report, wa will limit ourselves to describing 
tha tatt executive software. 
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FIGURE 4-1 SIMULATOR SELF TEST 
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4.1 SELF TEST EXECUTIVE SOFTWARE 

A software flow for tho tost executive It shown In Figure 4-2. Tho tost 
executive Is primarily concomtd with controlling tho order and oxtont of tho 
tostlng oxocutod and communicating tho propor output mossagos and data for 
operator uso as wall as for storage In tho data base for Incipient fault 
detection. Tho tost executive accomplishes Its function by Initiating and 
controlling the loading of all test software from mass storage facilities, 
commanding execution of the tests, reviewing the processed results from the 
tests and then selecting the proper course of action which will Include In 
most cases, the presentation of data to the operator, the selection of 
additional tests, the storage of historical data In data base files, and the 
printing of test data reports. 

• 

It should be noted that the test executive does not become Involved In 
the dynamic test timing function. The test data sampling rates are established 
by the test software for each subsystem being tested. Time tags for the data 
points are obtained from an external clock and are loaded Into the controlling 
computer at the same time the data words are loaded. This minimises the depen- 
dence of the subsystem tests on proper operation of all computer and Interface 
timing functions and eliminates unpredictable Interrupts and Interrupt processing 
as an error source In test data timing. 

The executive does contain the logic to decide on the course of action 
after each level of testing Is completed. This logic requires access to the 
test results temporarily stored In a memory buffer. 

When testing Is completed or has proceeded to a standstill, the executive 
formats the data. If necessary, and communicates the appropriate Information 
as follows: 

o Operator display - Operator action requirements. Including "system ready" 

o Hardcopy printer - Dally test results summary and reference data 

o Data base file - Incipient fault data base update 
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Figure 4-2 SELF TEST EXECUTIVE SOFTWARE FLOW (continued) 
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4.2 SUBSYSTEM TEST SOFTWARE 

The subsystem test software, such «s FITST or HBTST, Is loaded by the 
executive, TESTEX, end Includes the programming which Implements the tests, the 
characteristic parameter data associated with the hardware being tested, and 
the date processing software required for reducing the test data. The output 
of the subsystem test software Is stored In a memory buffer for final disposition 
by the executive, TESTEX. 

There are three different types of testing/processing at the subsystem 
level. These consist of readiness testing, fault* Isolation testing, and Inci- 
pient fault detection processing, and are usually executed In that order. 

• , 

The readiness tests are Ideally end-to-end tests or total performance 
tests for a subsystem. If a readiness test Indicates a fault and fault 
Isolation tests are applicable, the decision to proceed with fault Isolation 
can be taken automatically at the subsystem test software level, and the logic 
Is shown accordingly as part of the subsystem tests. It Is recognized that 
this decision could be exercised at the executive level where the results of 
other concurrent subsystem tests could also be considered. The decision can 
also be reserved for manual selection by the operator. Final choices can be 
-‘made during software implementation wilhout any significant Impact on the 
software development. 

Incipient fault detection data should nominally be gathered during the 
readiness tests. If a fault Is detected at that time, the Incipient fault 
detection data may be adversely affected. Consequently, the decision should 
be made at the subsystem level to delete this data and not add It to the data 
base. Otherwise, the Incipient fault detection data Is communicated to the 
executive through the memory buffer. 
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SECTION 5 

SELF TEST SYSTEM HARDWARE 

Tbit section summarizes the total hardware requirements to Implement the 
simulator Self Test System developed In the course of the study. The hardware 
listed Includes only those components added for test purposes. A primary ground- 
rule of the study was to maximize use of operational hardware In carrying out 
the Self Test Job. This groundrule has been adhered to throughout the study, 
and hardware used In this manner Is not specifically Identified In this section. 

Cost data on Self Test System hardware Is presented and discussed In Section 7. 

Table 5.0-1 Is a list of the various components added to each of the sub- 
systems for Self Test purposes. Each photosensor used for galvanometer testing 
Include a photodiode as a built-in light source. These devices are compatible 
with signal levels of logic circuitry used In the Data Conversion Equipment and 
therefore, no additional signal conditioning components are needed. 

The current sensor circuits used to verify operation of lighted Indicators 
are counted as a single component per Indicator. These sensor circuits contain 
resistors, diodes, and transistors. However, each sensor circuit can be packaged 
as an Individual module and using state of the art circuit Integration techno- 
logy, the circuits could be packaged right In the Indicator assembly. 

The loop closure switches lifted for the Analog DCE are those solid state 
switches used to connect output channels to Input channels In order to verify 
DCE operational status. Also under DCE Is Included the necessary components, 

ADC, switches, and buffer amplifiers needed to provide Input channels for 
measurements taken during the Self Test process, measurements using Instru- 
mentation specifically added as part of the Self Test System. 

Table 5.0-2 shows the breakdown of additional DCE channel requirements for 
Self Test. These requirements cover the data acquisition channels used speci- 
fically to measure characteristic parameters of simulator hardware during 
Readiness, Fault Isolation, or Incipient Fault Detection testing. No additional 
coimtand channels were Identified for applying test stimuli to operational hardware. 

5-1 
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TABLE 5.0-1 HARDWARE ADDED FOR SELF TEST 


COMPONENT QUANTITY 

Galvanometers (70) 

3 photosensors In each 210 

• • 

Lighted Indicator Current Sensor Circuits 700 

Analog DCE - Loop Closure Switches 

Closure to test Input channels 200 

Crew station Isolation and connection of output 
channels to the 200 operational Input channels 200 


Analog DCE Test Channel Components 
ADC 

Buffer amplifiers 

Solid state analog switches 


1 

120 * 
120 


Bilevel DCE - Loop Closure Gating and 

Digital Input Multiplex Selection Gates 2500 


Visual Simulation System Self Test Hardware. 


Digital processing oscilloscope 

Signal generator 1 
Signal to noise meter 1 
Video switches 16 
Video buffer amplifiers 36 


Motion Base 

Pressure sensors 5 
Level sensor 4 
Temp sensor 2 


. • . 

• 

•• • 

• 

• 
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TABLE 5.0-2 ADDITIONAL DCE CHANNEL REQUIREMENTS FOR SELF TEST 


COMPONENT TESTEO 

CHANNEL REQUIREMENTS 


• 

Gal variometers 

Bilevel. 

210 

Analog 

Servometers 

• 

• 

16 

Tapemeters 


20 

• 

ADI (4 units) 

4 wire sln/cos, 3 channels each 
6 pointer position feedback 
signals from each ADI 

48 

• 

24 

• 

Lighted Indicator 

700 


Electromechanical Flags 

400 • 


•’Switches - No extra liner for testing 

mmm 


• 

Visual Model Servos 
3 cameras x 6 servos 
Terminal area transport servos 
Orbital earth position resolver 
Cloud/sky/ terminator altitude servos 

■ 30 

i 

• 

18 

4 

3‘ 

Motion Base 

Sensors 1 1 

Position, actuators 6 

• 

• 

17 


1388 

102 

With Sp res 

• 

1500 

125 

» • »•* • • 
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However. In the cate of the video components of the Visual Simulation System, the 
test controlling computer, with OCE, must Issue the necessary commands to re- 
configure the test hardware and control the test execution. These commands acti- 
vate the DPO* signal generators* and measuring equipment used to test video 
elements. The number of these commands Is relatively small (less than 20) and 
represent negligible Impact on the total OCE. 

On the other hand, the additional Input channel requirements of 1500 bi- 
level and 125 analog channels for Self Test purposes represent an effective 
doubling of OCE capability when compared with the Reference Configuration 
magnitudes of 2000 bilevel and 100 analog channels. Considerable Increase 
In parts and manufactuflng cost should be expected from the fact that the In- 
crease In OCE capability Is more accentuated on the analog Instead of. the bilevel * 
side of the OCE. Analog channel components are larger, more complex, and more 
costly than the gating required to add bilevel channels. 


Additional test hardware for the Visual Simulation System consists 
of the Digital Processing Oscilloscope, a video test waveform generator, a 
signal to noise meter, and the necessary switching to Isolate each LRU 
during the testing sequence. No additional hardware Is expected for testing 
model scene generation equipment other than that listed under DCE. 


The Motion Base test hardware consists of the sensors and signal conditioning 
circuits required to route characteristic parameter data to the computer. Normally 
these parameters are only routed to the maintenance panel either electrically, 
mechanically, or hydraulically. In order to Implement the automatic Self Test 
capability developed In this study, It Is also necessary to digitize charac- 
teristic parameter data and supply them to the computer conducting the test. 

The amount of hardware discussed above Is a significant measure of the 
Impact on simulator design and maintenance by the addition of automatic Self 
Test. Cost data related to this Impact Is discussed In Section 7. However, 
at this point It Is Important to point out that parts cost Is a small part of 
total Impact when compared with the total cost that Includes generation of 
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additional wiring Instructions, manufacturing additional housing spaca for thosa 
components, actual wiring cost, and Incraasa In accaptanca and Intagratad tast- 
ing of tha resulting system. All of these costs, however, may be offset by the 
Incraasa achieved In simulator availability and utility during tha operational 
life of tha system. They also represent a vary small percent Incraasa to 
simulator total procurement cost. 



HOC Ell 49 
20 September 1974 


SECTION 6 . 

SYSTEM IMPACT BY REQUIREMENTS OR DESIGN CHANGES 

This section discusses various types of changes that can occur after the 
simulator has become operational and the sources of changes. Particular 
attention Is given to the Impact of these changes both on the Simulator 
System as well as In the Self Test System. This discussion Is the basis for 
assessing the effect of changes on the operational simulator and Simulator 
Self Test systems, and for formulating some reconmendatlons that could 
minimize Impact. 

6.1 SOURCES OF CHANGE 

As Indicated above, this section only deals with changes Initiated after 
the simulator has been Installed, accepted, and Is In Its operational phase. 
Changes during design or development of the simulator per se are not considered 
here, because these changes are allowed a greater Impact than those during 
the operational phase, and also because when considering the Implementation 
of development changes, the Impact of these changes on other parts of the 
system Is evaluated before permitting Implementation. 

The major sources ctf changes during the operational life of the Simulator are: 

1. Mission peculiar requirements variation from flight to flight. 

2. Vehicle design changes. 

3. Advancements in state of the art and 

4. Performance enhancements. 

These sources of change are discussed below. 

6.1.1 Mission Peculiar Requirements Variations 

The primary mission of Shuttle simulators Is to provide a training facility 
for the various piloting and mission oriented crews that will man Shuttle 
controls during the life of the program. Although the aerodynamic and vehicle 
performance characteristics will not vary considerably from flight to flight. 

It Is reasonable to expect significant changes In mission objectives, payload 
management requirements, and general procedures as dictated by the type of 
trajectory, orbital characteristics, and manueverlng requirements needed to 
accomplish these mission objectives. 
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Million related changes manifest themselves In the Simulator In the need 
for special payload management controls, payload related math models, and 
development of procedures that permit efficient utilization of vehicle and 
payload systems In accomplishing mission objectives. A dramatic example of 
mission related Simulator changes Is the addition of payload environmental 
control and life support management facilities in the crew station, as well 
as the addition of math model restrictions In payload manipulation when 
changing Simulator configuration from a Shuttle carrying only unmanned pay- 
loads, to one carrying a mix of manned and' unmanned payloads. 

6.1.2 Vehicle Design Changes 

This source of Simulator changes Is more difficult to visualize at this 
point In the Shuttle program. The design of the vehicle Is an ongoing effort, 
and additions and changes are taking place on a dally basis. It would be 
Ideal If this process could achieve an optimal configuration prior to the 
first space flight, however, experience In previous programs has shown 
otherwise, and therefore, It Is reasonable to expect design changes to take 
place as problems become more apparent during early flights of the Shuttle. 

Design changes may affect vehicle performan * i or payload accomodation 
facilities and consequently alter the control and displays layout In the 
crew station, as well as the looks, feel or sound of related cues. 

6.1.3 State of the Art Advancements 

Even more difficult to visualize than vehicle design changes are those 
modifications that result from advances In the state of the art of simulator 
hardware. Generally, these modifications result In the replacement of multiple 
components for an Integrated system that performs the same job more effectively. 
Effectiveness In this case refers to fidelity of simulation as a primary 
Intention, and cost of ope-ttlon when compared with the price of Implementing 
the change. 

6.1.4 Performance Enhancement 

The fourth source of simulator modifications Is the need to Improve perfor- 
mance of the simulator beyond that which was specified, and supposedly met as 
shown by acceptance test results. Again, the'prlmary consideration In this 
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cm It fidelity of simulation. The situation may dtvolop such that although 
tho simulator performs at specified. It does not present realistic cues to the 
crew so that positive training can take place lii an environment that truly 
represents the vehicle In looks, feels, sound, and performancei co sequently, 
modifications are needed to enhance the simulation capability of toe system. 

• 

Performance enhancement changes would generally manifest themselves In 
the Installation of new equipment, or replacement of existing components with 
units that have more capability. These changes would usually result In an 
Increase of complexity In the simulator system, and therefore Increase the 
need for control as well as data acquisition channels In quantity and sometimes 
In capability. 
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6.2 IMPACT OF SIMULATOR CHANGES 

Implementation of changes on the simulator system requires additions, 
deletions, and reconfiguration of hardware and software. This Impact will affect 
simulation as well as self test elements. In many cases, also, the character- 
istic parameter data base will be Impacted. Table 6.2-1 Itemizes the Impact 
of various changes on the affected elements of the system. 

The Impact analysis for changes In Interface minicomputers, visual simu- 
lation, and motion base Is unnecessary since changes In these subsystems are 
unlikely after simulator acceptance. These subsystems are large, complex, 
and generally the subject of Individually managed procurement efforts. This 
special attention In procurement yields comprehensive requirement specifications 
for components that are reliable, maintainable, and capable of meeting future 
needs of the simulator 

The Crew Station and I0S control and display elements may be changed 
either by vehicle changes, mission requirement changes, or the need to Improve 
fidelity of simulation. Flight hardware used as part of the simulator system 
may al . t * the subject of change by either of the reasons mentioned above. 

The change* shown on Table 6.2-1 for the DCE generally result from changes In 
Crew Station and IDS controls and displays or In simulator Flight Hardware. 

Minor changes may develop to take care of needs for additional control or 
Instrumentation of simulator functions. 

Notice that the changes discussed may originate from needs to modify the 
simulation system, or from needs to modify the simulator Self Test System. 

Changes In one system generally Impact configuration of the other system. 

This relationship Is shown In the Table. Also, It should be no.ted that the 
characteristic parameter data base, as expected, Is only affected when new 
hardware Is Introduced Into the system, or when some hardware Is removed or 
replaced. 


6-4 


MCOOWWVLL OOUOL4S 4SrfrOW4(/rtCfl OOMi 


r - KMmr 



TABLE S.Z-1 IfTACT OF S 



ORIGINAL PAGE IS 
OF POOR QUALITY 


JMCf 











.HOC E1149 

20 September 1974 

SECTION 7 

SELF TEST SYSTEM C05T DATA 

Relative cost data for addition of automatic self tost capability to tho 
Raforonco Configuration Simulator It shown In Tablo 7.0-1. No absolute dollar 
figures art shown btcaust the sal action of ttst component configuration, packaging, 
manufacturing, and Installation techniques are dependent on the actual simulator 
design used, as well as the date In time when self test system Implementation 
is to take place. 

• • 

The first column shows cost of self test system elements relative to the 
basic cost of the subsystem to be tested. This rating ranges from Negligible 
(0-52) to Moderate (20-3OX). No "High" ratings were given to self test cost 
for any subsystem as this rating would have Implied greater than a 502 Increase 
In cost of the basic system. Consistent utilization of existing operational 
capability In the system for self test purpose Is the basic reason for maintaining 
cost between Moderate and None. 

The five columns to the right of the Table show cost of different factors 
In Implementing subsystem self test as a percentage of total Self Test System 
•* cost. Some of these factors are estimated as less than 12 and therefore are 
shown only as *. The total cost of the Self Test System adds only to 982; 
the remaining 22 Is accounted for In the w Items and others which exceed the 
whole number shown. 

The largest percentage of Self Test System cost appears In Visual Simulation 
CCTV Self Test. This high percentage Is due to the cost of the Digital Processing 
Osscllloscope, the special video pattern test signal generators, and the various 
signal and noise meters. The cost of visual simulation video component self 
test Is further Increased by test software development cost. This software Is 
relatively more sophisticated than other elements of the test software In that 
It must provide processing capability for various complex waveforms from the 
video string. These waveforms have a variety of frequency components, require 
sampling rates of up to 50 Megahertz, and Include test patterns such as a stair 
step and frequency multi burst signals. 



TABLE 7.0-1 RELATIVE COST FACTORS OF SELF TEST SYSTEM 
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Following closely In percentage of cost It th« Crow Station and I0S self 
tost factors. The high cost of controls and displays chockout Is owod to tho 
largo nuinbor and varloty of components to bo tested, which In turn roqulros a 
fairly largo charactorlstlc parameter data base. In addition to tho data baso 
software, a generalized routine must bo developed for each of tho typos of 
components used. Each component must bo tostod Individually and therefore 
requires Its own unique tost calling and control sequence. With component 
count In the hundreds (thousands. If switches Included), It can be seen that 
these sequences make up a considerable amount of software to be written, 
Integrated* tested, and documented. Also, the large number of components 
affect design, manufacturing, and test component costs to make Crew Station 
and I OS self test a high portion of total Self Test System cost. 
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The system level analyses e f the simulator and automatic self test concepts 
have yielded several conclusions that help understand the self test process and 
the self test system as such. This understanding- contributes to comprehensive! 
realistic and Integrated requirements definition, while at the same time providing 
a picture of the cost of self test Implementation relative to the operational 
advantages gained by Its presence In the simulator system. 

• 

First of all, It was determined that three levels of testing are required 
to achieve effective operational utility of the Self Test System, and Increase 
availability of the simulator. Readiness Tests yield Information as to oper- 
ational health of each subsystem. Fault Isolation Tests are called upon to 
determine which LRU, If any, has failed. Incipient Fault Detection Tests gather 
performance degradation data to schedule maintenance of degraded components 
before an actual failure occurs. The DCE, Motion Base, and Visual Simulation 
subsystems can be adequately checked at the functional level; only If a fault 
exists Is It necessary to call the more detailed Fault Isolation Test. Other 
subsystems must be tested at the LRU level In order to ascertain readiness. 
Incipient Fault Detection techniques were found to be effectively applicable 
to the Motion Base System, the Visual Simulation elements, and to servo driven 
Instrumentation. 

A software structure for the Self Test system was developed. This structure 
Conforms to the operational considerations brought about by the three categories 
of testing mentioned above, and depends largely on the use of utility test 
‘ modules that minimize redundancy and maximize programming efficiency. 

No significant Increase In hardware was found to be needed to Implement the 
simulator self test capability developed In the course of the study. On a 
subsystem basis, the relative cost of adding self test hardware was found to be 
from moderate to none. The greatest hardware Impact Is found In the DCE because 
of the more than 100% Increase In number of analog channels, and In the Visual 
Simulation because of the Digital Processing Oscilloscope, signal generators, and 
signal meters needed to perform specially designed video component tests. 
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Change Impact analysis Indicated that changes ‘occurring during operational 
phase of the simulator would be felt most In Crew Station and IOS controls and 
displays. In the Flight Hardware components of the simulator, and In the DCE. 
The magnitude of this Impact cannot be assessed a priori, as the effect of a 
change greatly depends on the nature of the change and the components Involved. 
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